[pull] canary from vercel:canary - #1321

…suite (#97540)

This suite doesn't use `sqlite3`.

…cal addon fixture (#97541)

The suite installed `sqlite3` only to get a package that locates its
compiled binary through `require('bindings')(...)`, which is the shape
turbopack issue 5913 was about. It now carries its own `native-addon`
and `bindings` packages instead, both installed as relative `file:`
dependencies, with node-gyp compiling the addon during install.

The addon is compiled rather than stubbed because the assertion reads a
value off the loaded binary, so a real `process.dlopen()` has to happen.
Compiling at install time also keeps the binary matched to whichever
Node ABI is running, which a checked-in binary could not do, since a
non-context-aware addon cannot use Node-API and is therefore ABI-locked.
The page now renders the addon's constant, so a module that resolved to
nothing fails the test instead of passing quietly.

Both packages are `file:` rather than `link:` dependencies. A linked
package resolves to a path inside the app, which the bundler then treats
as app code and tries to bundle, and `bindings` contains a `require` it
cannot resolve statically. `serverExternalPackages` is needed because
the app router bundles `node_modules` by default, and `sqlite3` only
avoided that by being on the built-in list in
`server-external-packages.jsonc`.

The fixture packages are registered in `modulePathIgnorePatterns`,
following the entries already there. Jest is configured with
`throwOnModuleCollision`, so a package name appearing twice outside
`node_modules` aborts the whole test run, and the layers above add more
copies of `bindings`.

…ackages (#97542)

This suite installed `sqlite` and `sqlite3` on every run to prerender a
page from a checked-in SQLite database. Neither package was needed for
what the test covers. The pinned `sqlite3@5.0.2` has no linux-arm64
prebuild, and every job that runs this suite is linux-arm64, so each one
compiled the SQLite amalgamation from source. That pin is also Node-API
based and therefore context-aware, so it could no longer reproduce the
abort the suite was originally added for.

The fixture now uses its own compiled `native-addon` plus a
dependency-free JS wrapper standing in for `sqlite`'s role, and reads
its rows from a plain JSON file. The `path.join(process.cwd(), ...)`
expression stays in the page, because output file tracing only follows
it from the app's own code, so moving it into the wrapper would stop the
data file being traced.

The emitted traces were read rather than assumed. Turbopack and
`@vercel/nft` produce the same fixture entries, including the compiled
binary at `native-addon/build/Release/native_addon.node` and the
`process.cwd()`-derived `users.json`.

The trace assertion now checks each pattern separately instead of
collapsing them into a single `every(...)`, which could only report that
something did not match. The `notTests` block went away with it, since
`[].some(...)` asserted nothing.

…trol (#97543)

`experimental.workerThreads` decides whether static generation runs in
real worker threads or forked child processes, and a native addon
declared with `NODE_MODULE` can only be loaded once per process. That is
why the flag defaults to false (#9199) and why the static export worker
was fixed to respect it rather than hardcoding threads on (#25063).
Nothing tested it: the only suite that tried, `firebase-grpc`, had its
assertion skipped since 2019, and modern `firebase` ships no native
module at all, so its remaining test asserted only that a build
succeeds.

This adds a `single-context-addon` fixture, deliberately declared with
`NODE_MODULE`, and a production suite asserting both directions: the
build succeeds by default and fails with "Module did not self-register"
once worker threads are enabled. The fixture loads the addon from
`next.config.js` as well as from the page, because that failure only
happens on a second `dlopen` within one process, so an addon loaded only
inside the worker would register there and the build would pass.

A third case documents a bug rather than intended behaviour. `next
build` runs Turbopack in a worker thread and that worker re-evaluates
`next.config.js`, so requiring a non-context-aware addon from the config
breaks the build even with `experimental.workerThreads` off. Webpack and
rspack are unaffected, since their build workers are forked child
processes. Isolated with an unguarded `require` and default flags,
Turbopack exits 1 with "Module did not self-register" where webpack
exits 0. It is the same class of failure #9199 and #25063 fixed, in a
worker those PRs did not touch. The assertion is branched on the bundler
and carries a note to drop the branch once Turbopack stops evaluating
the config on a worker thread. The `isMainThread` guard in the fixture's
config keeps the first two cases pointed at the static generation worker
instead.

A development suite covers the other direction, asserting that
evaluating a route does not put such an addon on one of the threads
`next dev` uses regardless of the flag, so it would catch a change that
moved route evaluation onto the dev validation pool. The expectation is
the same with and without Cache Components; both were checked by logging
the thread id from the page's module scope, and the route is evaluated
on the main thread either way.

`firebase-grpc` is removed, since it covered the same flag with a
skipped assertion and a vacuous one.

### What?

Use GitHub's raw content endpoint to validate the `package.json` for
create-next-app examples supplied as repository URLs.

### Why?

The previous validation used GitHub's unauthenticated Contents API.
Parallel create-next-app tests can exhaust the shared runner IP's low
API quota, after which valid examples are reported as missing before
download or package-manager installation begins.

This surfaced as `EPERM` because execa labels a child exit code of `1`
with Node's matching errno name; the underlying create-next-app output
showed the repository lookup failure.

### How?

Probe the example's `package.json` directly on
`raw.githubusercontent.com`. This preserves the existing existence check
while removing the rate-limited API request from URL-based example
creation. The actual archive download continues to use
`codeload.github.com` as before.

### Verification

- `IS_WEBPACK_TEST=1 NEXT_TEST_MODE=start pnpm test-start
test/production/create-next-app/package-manager/yarn.test.ts`
- `pnpm build-all`
- `pnpm --filter create-next-app build`
- `pnpm types`

<!-- NEXT_JS_LLM -->

Co-authored-by: vercel-fleet-prod[bot] <318278635+vercel-fleet-prod[bot]@users.noreply.github.com>
Co-authored-by: Tobias Koppers <1365881+sokra@users.noreply.github.com>

Using `keyv` instead of `sqlite3`. This test never installed the package
but it just looked like it's native binding related due to its choice of
package.

## Summary

- keep incompatible segment config migration before the codemod
- move synchronous IO fixes after the codemod and normal build so
`connection()` is applied only to reported blockers
- use a scoped debug build only when the normal build does not locate
the reported call

## Verification

- Not run: product tests (agent skill guidance only)

<!-- NEXT_JS_LLM -->